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Abstract 

Max Restricted Path Consistency (maxRPC) is a local consistency for 
binary constraints that can achieve considerably stronger pruning than arc 
consistency. However, existing maxRPC algorithms suffer from overheads 
and redundancies as they can repeatedly perform many constraint checks 
without triggering any value deletions. In this paper we propose techniques 
that can boost the performance of maxRPC algorithms. These include the 
combined use of two data structures to avoid many redundant constraint 
checks, and heuristics for the efficient ordering and execution of certain op- 
erations. Based on these, we propose two closely related maxRPC algo- 
rithms. The first one has optimal 0(end 3 ) time complexity, displays good 
performance when used stand-alone, but is expensive to apply during search. 
The second one has 0(en 2 d 4 ) time complexity, but a restricted version with 
0{end 4 ) complexity can be very efficient when used during search. Both 
algorithms have 0(ed) space complexity when used stand-alone. However, 
the first algorithm has O(end) space complexity when used during search, 
while the second retains the O(ed) complexity. Experimental results demon- 
strate that the resulting methods constantly outperform previous algorithms 
for maxRPC, often by large margins, and constitute a more than viable alter- 
native to arc consistency. 

1 Introduction 

maxRPC is a strong domain filtering consistency for binary constraints introduced 
in 1997 by Debruyne and Bessiere [5]. maxRPC achieves a stronger level of lo- 
cal consistency than arc consistency (AC), and in |6l it was identified, along with 
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singleton AC (SAC), as a promising alternative to AC. Although SAC has received 
considerable attention since, maxRPC has been comparatively overlooked. The 
basic idea of maxRPC is to delete any value a of a variable x that has no arc con- 
sistency (AC) or path consistency (PC) support in a variable y. A value b is an AC 
support for a if the two values are compatible, and it is also a PC support for a if 
this pair of values is path consistent. A pair of values (a, b) is path consistent iff 
for every third variable there exists at least one value, called a PC witness, that is 
compatible with both a and b. 

The first algorithm for maxRPC was proposed in 0, and two more algorithms 
have been proposed since then (7J[T0l. The algorithms of Q and ifTUl have been 
evaluated on random problems only, while the algorithm of Q has not been ex- 
perimentally evaluated at all. Despite achieving considerable pruning, existing 
maxRRC algorithms suffer from overhead and redundancies as they can repeatedly 
perform many constraint checks without triggering any value deletions. These con- 
straint checks occur when a maxRPC algorithm searches for an AC support for a 
value and when, having located one, it checks if it is also a PC support by look- 
ing for PC witnesses in other variables. As a result, the use of maxRRC during 
search often slows down the search process considerably compared to AC, despite 
the savings in search tree size. 

In this paper we propose techniques to improve the applicability of maxRPC by 
eliminating some of these redundancies while keeping a low space complexity. We 
also investigate approximations of maxRPC that only make slightly fewer value 
deletions in practice, while being significantly faster. We first demonstrate that 
we can avoid many redundant constraint checks and speed up the search for AC 
and PC supports through the careful and combined application of two data struc- 
tures already used by maxRPC and AC algorithms (7J[l0l|2l[8l|9l. Based on this, 
we propose a coarse-grained maxRPC algorithm called maxRPC3 with optimal 
0(end 3 ) time complexity. This algorithm displays good performance when used 
stand-alone (e.g. for preprocessing), but is expensive to apply during search. We 
then propose another maxRPC algorithm, called maxRPC3 rm . This algorithm has 
0(en 2 d 4 ) time complexity, but a restricted version with 0(end 4 ) complexity can 
be very efficient when used during search through the use of residues. Both algo- 
rithms have 0(ed) space complexity when used stand-alone. However, maxRPC 3 
has O(end) space complexity when used during search, while maxRPC 3 rm retains 
the 0(ed) complexity. 

Similar algorithmic improvements can be applied to light maxRPC (ImaxRPC), 
an approximation of maxRPC lITOll . This achieves a lesser level of consistency 
compared to maxRPC but still stronger than AC, and is more cost-effective than 
maxRPC when used during search. Experiments confirm that ImaxRPC is indeed 
a considerably better option than maxRPC. 
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We also propose a number of heuristics that can be used to efficiently order 
the searches for PC supports and witnesses. Interestingly, some of the proposed 
heuristics not only reduce the number of constraint checks but also the number of 
visited nodes. 

We make a detailed experimental evaluation of new and existing algorithms on 
various problem classes. This is the first wide experimental study of algorithms 
for maxRPC and its approximations on benchmark non-random problems. Results 
show that our methods constantly outperform existing algorithms, often by large 
margins. When applied during search our best method offers up to one order of 
magnitude reduction in constraint checks, while cpu times are improved up to four 
times compared to the best existing algorithm. In addition, these speed-ups enable 
a search algorithm that applies ImaxRPC to compete with or outperform MAC on 
many problems. 

2 Background and Related Work 

A Constraint Satisfaction Problem (CSP) is defined as a tuple (X, D, C) where: 
X = {x\, . . . , x n } is a set of n variables, D = {D(x\), . . . , D(x n )} is a set of do- 
mains, one for each variable, with maximum cardinality d, and C = {c\, . . . , c e } is 
a set of e constraints. Each constraint c is a pair (var(c), rel(c)), where var(c) = 
{xi, . . . ,x m } is an ordered subset of X, and relic) is a subset of the Carte- 
sian product D{x\) x ... x D{x m ) that specifies the allowed combinations of 
values for the variables in var{c). In the following, a binary constraint c with 
var{c) = {x-i,Xj} will be denoted by Cjj, and D{xi) will denote the current do- 
main of variable X{. Each tuple r € rel(c) is an ordered list of values (a±, . . . , a m ) 
such that aj € D(xj),j = 1, . . . ,m. A tuple r G reZ(cj) is valid iff none of 
the values in the tuple has been removed from the domain of the corresponding 
variable. 

The process which verifies whether a given tuple is allowed by a constraint c is 
called a constraint check. A binary CSP is a CSP where each constraint involves 
at most two variables. We assume that binary constraint checks are performed in 
constant time. In a binary CSP, a value G D{xi) is arc consistent (AC) iff for 
every constraint Qj there exists a value dj 6 D(xj) s.t. the pair of values (aj, aj) 
satisfies c^. In this case aj is called an AC-support of aj. A variable is AC iff all 
its values are AC. A problem is AC iff there is no empty domain in D and all the 
variables in X are AC. 
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2.1 maxRPC 



A value aj E D(xi) is max restricted path consistent (maxRPC) iff it is AC and 
for each constraint c-ij there exists a value aj £ D(xj) that is an AC-support of aj 
s.t. the pair of values (aj, aj) is pctf/i consistent (PC) (H. A pair of values (ai,aj) 
is PC iff for any third variable there exists a value 6 D(xk) s.t. a^ is an 
AC-support of both aj and aj. In this case a.,- is a PC-support of aj in and is 
a PC-witness for the pair (aj, a^) in A variable is maxRPC iff all its values are 
maxRPC. A problem is maxRPC iff there is no empty domain and all variables are 
maxRPC. 

To our knowledge, three algorithms for achieving maxRPC have been proposed 
in the literature so far. The first one, called maxRPCl, is a fine-grained algorithm 
based on AC 6 and has optimal 0(end 3 ) time complexity and O(end) space com- 
plexity [|5]]. The second algorithm, called maxRPC2, is a coarse-grained algorithm 
having 0(end 3 ) time and O(ed) space complexity Q . Finally, maxRPC™ 71 is a 
coarse-grained algorithm based on AC3 rm ifTOll . The time and space complexi- 
ties of maxRPC" 71 are 0(en 2 d 4 ) and O(end) but it has some advantages compared 
to the other two because of its lighter use of data structures. Among the three 
algorithms maxRPC2 seems to be the most promising for stand-alone use as it 
has a better time and space complexity than maxRPC rm without requiring heavy 
data structures or complex implementation as maxRPCl does. On the other hand, 
maxRPC rm can be better suited for use during search as it avoids the costly main- 
tainance of data structures. 

Central to maxRPC 2 is the Last PC data structure, as we call it here. For 
each constraint c- L j and each value aj € D(x-i), LastPC XiAi)X . gives the most 
recently discovered PC-support of aj in D(xj). maxRPC2 maintains this data 
structure incrementally. This means that the data structure is copied when moving 
forward during search (i.e. after a successfully propagated variable assignment) 
and restored when backtracking (after a failed variable assignment). This results in 
the following behavior: When looking for a PC-support for a, in D(xj), maxRPC 2 
first checks if LastPC Xt! a i:X is valid. If it is not, it searches for a new PC-support 
starting from the value immediately after LastPC Xuai:Xj in D(xj). In this way 
a good time complexity bound is achieved. On the other hand, maxRPC" 77 uses 
a data structure similar to LastPC to store residues, i.e. supports that have been 
discovered during execution and stored for future use, but does not maintain this 
structure incrementalljQ. When looking for a PC-support for aj in D(xj), if the 
residue LastPC x%: a uXj is not valid then maxRPC™ searches for a new PC-support 
from scratch in D(xj). This results in higher complexity, but crucially does not 
require costly maintainance of the LastPC data structure during search. 

'maxRPC™ also uses residues in a different context. 
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A major overhead of both maxRPC2 and maxRPC" 71 is the following. When 
searching for a PC- witness for a pair of values (aj, aj) in a third variable x^, they 
always start the search from scratch, i.e. from the first available value in D(xk). 
As these searches can be repeated many times during search, there can be many re- 
dundant constraint checks. In contrast, maxRPCl manages to avoid searching from 
scratch through the use of an additional data structure. This saves many constraint 
checks, albeit resulting in O(end) space complexity and requiring costly main- 
tainance of this data structure during search. The algorithms we describe below 
largely eliminate these redundant constraint checks with lower space complexity, 
and in the case of maxRPC3 rm with only light use of data structures. 

3 New Algorithms for maxRPC 

We first recall the basic ideas of algorithms maxRPC2 and maxRPC rm as described 
in and iflQl . Both algorithms use a propagation list L where variables whose 
domain is pruned are added. Once a variable Xj is removed from L all neighboring 
variables are revised to delete any values that are no longer maxRPC. For any value 
en of such a variable Xj there are two possible reasons for deletion. The first, which 
we call PC-support loss hereafter, is when the unique PC-support aj € D(xj) for 
<ij has been deleted. The second, which we call PC-witness loss hereafter, is when 
the unique PC-witness aj £ D(xj) for the pair (0^,0^), where a& is the unique 
PC-support for aj on some variable Xk, has been deleted. In both cases value aj is 
no longer maxRPC. 

We now give a unified description of algorithms maxRPC 3 and maxRPC 3 rm . 
Both algorithms utilize data structures LastPC and Last AC which have the fol- 
lowing functionalities: For each constraint Cij and each value € D(xi), 
LastPC Xij a tjXj and LastAC Xuai)Xj give (point to) the most recently discovered 
PC and AC supports of in D(xj) respectively. Initially, all LastPC and Last AC 
pointers are set to a special value NIL, considered to precede all values in any do- 
main. Algorithm maxRPC 3 updates the LastPC and Last AC structures incre- 
mentally like maxRPC 2 and AC 2001/3.1 respectively do. In contrast, algorithm 
maxRPC3 rm uses these structures as residues like maxRPC"™ and AC" 71 do. 

The pseudocode for the unified description of maxRPC3 and maxRPC3 rm is 
given in Algorithm [T] and Functions [2 13 |U We assume the existence of a global 
Boolean variable RM which determines whether the algorithm presented is in- 
stantiated to maxRPC3 or to maxRPC3 rm . If RM is true, the algorithm used is 
maxRPC3 rm . Otherwise, the algorithm is maxRPC3. 

Being coarse-grained, Algorithm Q] uses a propagation list L where variables 
that have their domain filtered are inserted. If the algorithm is used for preprocess- 
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ing then, during an initialization phase, for each value m of each variable Xi we 
check if a, is maxRPC. If it is not then it is deleted from D{xi) and x^ is added 
to L. The initialization function is not shown in detail due to limited space. If the 
algorithm is used during search then L is initialized with the currently assigned 
variable (line 3). 

In the main part of Algorithm [T] when a variable Xj is removed from L, each 
variable X{ constrained with Xj must be made maxRPC. For each value ai € D(xi) 
Algorithm [T] like maxRPC 2 and maxRPC rm , establishes if is maxRPC by 
checking for PC-support loss and PC-witness loss at lines 8 and 12. 

Algorithm 1 maxRP C 3 /maxRPC 3 rm 



1: if -i RM then 

2: if -iinitialization(L, LastPC, LastAC) then return FAILURE; 
3: else L = {currently assigned variable}; 
4: while L ^ do 

5: h=L-{xj}; 

6: for each i, 6 X s.t. Cij G C do 

7: for each a, 6 D(xi) do 

8: if —•searchPCsup(a,i , Xj ) then 

9: delete a^; 

10: L^Uix,}; 

1 1 : else 

12: if -^checkPCwit(ai , xj ) then 

1 3 : delete a; ; 

14: L=LU{i,); 

15: if D(xi) is empty then return FAILURE: 

16: return SUCCESS; 



First, function searchPCsup is called to check if a PC-support for ai exists in 
D(xj). If value LastPC x%:auX . is still in D(xj), then searchPCsup returns TRUE 
(lines 1-2). If LastPC Xuai)Xj is not valid, we search for a new PC-support. If 
maxRPC 3 is used, we can take advantage of the LastPC and LastAC pointers to 
avoid starting this search from scratch. Specifically, we know that no PC-support 
can exist before LastPC XiAi)Xj , and also none can exist before LastAC XuauXj , 
since all values before LastAC XuauX ■ are not AC-supports of aj. Lines 5-6 in 
searchPCsup take advantage of these to locate the appropriate starting value bj. 
Note that maxRPC2 always starts the search for a PC-support from the value after 
LastPC Xuai:Xj . If the algorithm is called during search, in which case we use 
maxRPC3 rm then the search for a new PC-support starts from scratch (line 8), just 
like maxRPC"™ does. 

For every value aj 6 D(xj), starting with bj, we first check if is an AC- 
support of a{ (line 10). This is done using function isConsistent which simple 
checks if two values are compatible. If it is, and the algorithm is maxRPC3, then 
we can update LastAC Xi ^ a ^ Xj under a certain condition (lines 12-13). Specifically, 
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if LastAC Xi: a uXj was deleted from D(xj), then we can set LastAC Xi>ai>x . to aj 
in case LastAC Xi , ai , Xj > LastPC Xi>ai>x .. If LastAC XitauXj < LastPC XuaiyXj 
then we cannot do this as there may be AC-supports for aj between LastAC Xua ^ Xj 
and LastPC XuaiiX . in the lexicographical ordering. We then move on to verify the 
path consistency of (aj, aj) through function searchPCwit. 

If no PC-support for a, is found in D{xj), searchPCsup will return FALSE, 
aj will be deleted and will be added to L. Otherwise, LastPC Xi>aitX . is set 
to the discovered PC-support aj (line 15). If maxRPC3 rm is used then we up- 
date the residue LastAC XuauXj since the discovered PC-support is also an AC- 
support. In addition, to exploit the multidirectionality of residues, maxRPC3 rm 
sets LastPC Xj7aj , Xi to a*, as in OH. 

Function 2 searchPCsup{ai, Xj):boolean 



1: if LastPC Xi ^a i ,x j £ D(xj) then 

2: return true; 

3: else 

4: if -. RM then 

5: if LastACx^a^xj € D(xj) then 6j = max(£astPC ;Cil0jI ; Ci +l,£astAC !EiJ a i)!E p; 

6: else bj =max(LastPC !E , iltH)! i; ;( +l,i/aat.<4.C iEi , ai^+l); 

7: else 

8: 6 j ■ = first value in D(xj ); 

9: for each aj 6 D(xj), aj > bj do 

10: if isConsistent(ai , aj ) then 

11: if -.RM then 

12: if LastACx^a^xj £ D(xj) AND LastAC Xil a i ,x j > LastPO Xi ,a it xj then 

13: LastAC,Bi,ai,xj = aj', 

14: if searchPCwit{a,i , aj ) then 

15: LastPCxi,ai,xj = aj', 

16: if RM then LastACxi^i^j = a.j\LastPC Xj , aj , Xi = a^; 

17: return true; 

18: return false; 



Function searchPCwit checks if a pair of values (aj,a_,) is PC by doing the 
following for each variable constrained with Xi and xjQ First, it checks if 
either LastAC x . a . x , is valid and consistent with a, or LastAC x . a . Xl is valid 
and consistent with aj (line 3). If one of these conditions holds then we have 
found a PC-witness for (<ij,aj) without searching in D{xk) and we move on to 
the next variable constrained with x% and Xj. Note that neither maxRPC2 nor 
maxRPC rm can do this as they do not have the Last AC structure. Experimental 
results in Section [5] demonstrate that these simple conditions can eliminate a very 
large number of redundant constraint checks. 

If none of the conditions holds then we have to search in D(xk) for a PC- 
witness. If the algorithm is maxRPC3 then we can exploit the Last AC structure 

2 Since AC is enforced by the maxRPC algorithm, we only need to consider variables that form a 
3-clique with Xi and Xj, 
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to start this search from b^ = max{LastAC Xiiai ,x k , LastAC Xjiaj ,x k } (li ne 6). But 
before doing this, we call function seekACsupport (not shown for space reasons), 
first with (xj, cii,Xk) and then with (xj, a,j,Xk) as parameters, to find the lexico- 
graphically smallest AC-supports for aj and a,j in D{x]A (line 5). If such supports 
are found, LastAC Xuai ,x k and LastAC x . ja . <Xk are updated accordingly. In case 
no AC-support is found for either a, or a,j then seekACsupport returns FALSE, and 
subsequently searchPCwit() will also return FALSE. 

Function 3 searchPCwit(a,i, aj ):boolean 

1: for each x k 6 V s.t. c ik g C and Cj k 6 C do 
2: maxRPCsupport=FALSE; 

3: if (LastAC Xi>ai ,x k 6 D(x k ) AND isConsistent(LastAC Xi , ai , Xk ,a.j)) OR (LastAC Xj , aj , Xk G 
D(x k ) AND isConsistent(LastAC Xj ,aj,x k , o-j)) then continue; 



if -i RM then 

if -^seekACsupport(xi, a,i,x k ) OR -^seekAC 'support(x j , aj , x k ) then return false; 
bfe = mozC&asMCzj , LastAC mj , aj , Xk ); 
else fefe = first value in D(x k ); 
for each S D(x k ), a k > b k do 

if isConsis1ent(a,i , a k ) AND isConsis1ent(aj , a k ) then 

if RM then LastAC Xi:ai , Xk = LastAC Xj , aj , Xk = a k \ 
maxRPCsupport=TRUE; break; 
if -imaxRPCsupport then return false; 
return true; 



If the algorithm used is maxRPC3 rm then we start search for a PC-witness 
from scratch (line 7), as maxRPC2 and maxRPC™ always do. If a PC-witness ak 
is found (line 9) and we are using maxRPC3 rm then both residues LastAC Xi) a t ,x k 
and LastAC Xj , aj ,x k are set to as they are the most recently discovered AC- 
supports. If no PC-witness is found then we have determined that the pair (ai,a,j) 
is not PC and as a result FALSE will be returned and searchPCsup will move to 
check if the next available value in D(xj) is a PC-support for <Zj. 

If value a, is not removed by searchPCsup in AlgorifhmQ] checkPCwit is called 
to check for PC-witness loss. This is done by iterating over the variables that are 
constrained with both x\ and Xj. For each such variable x^, we first check if 
ak = LastPC Xi: ai,x k is still in D(xk) (line 3). If so then we check if there still is 
a PC-witness in D(xj). This is done by first checking if either LastAC Xl:ai ,x is 
valid and consistent with ak or LastAC Xk: a k ,xj is valid and consistent with a» (line 
4). If neither of these conditions holds then we search for a PC-witness starting 
from bj = max{LastACx u ai,Xj, LastAC Xk! a k ,Xj} in case of maxRPC3 (line 9), 
after checking the existence of AC-supports for ^ and in D{xj), by calling 
seekACsupport (line 8). If there is no AC-support in D(xj) for either otj or ak we 
set the auxiliary Boolean variable findPCsupport to TRUE to avoid searching for a 
PC-witness. 

If maxRPC3 rm is used, we start searching for a PC-witness from scratch (line 
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11). Note that maxRPC2 does not do the check of line 4 and always starts the 
search for a PC-witness from the first value in D(xj). In contrast, maxRPC rm 
avoids some redundant checks through the use of special residues, albeit resulting 
in O(end) space complexity. When using maxRPC3 rm , for each value aj G D(xj) 
we check if it is compatible with a, L and and move the Last AC pointers accord- 
ingly (lines 14-15), exploiting the multidirectionality of residues, 



Function 4 checkPCwitifli, Xj):boolean 



for each n£V s.t. c ik g C and c k j £ C do 
witness=FALSE; findPCsupport=FALSE; 
if a k = LastPC Xi ,ai,x k 6 D(x k ) then 

if (LastAC XiiailX . £ D(xj) AND isConsistent(LastAC Xi ,a t ,xjt a k )) OR (LastAC Xk ,a l 
D(xj) AND isConsistent(LastACx k ,a k ,xj , cti)) then 

witness=TRUE; 
else 

if -1 RM then 

if seekAC support(xi, ai, Xj) AND seekACsupport(x k ,a k , Xj) then 

bj = max(LastAC Xit a i ,x j ,LastAC Xk ,a k ,x j ); 
else findPCsupport=TRUE; 
else bj = first value in D(xj); 
if —•findPC support then 

for each aj G D(xj), aj > bj do 

if isConsistent(ai , aj ) AND isConsistent(a k , aj ) then 

if RMthen LastAC Xi} ai, Xj = LastACx k ,a k ,x j = aj', 
witness=TRUE; break; 
if -witness AND exists a k > LastPCx i ,a i ,x k £ D(% k ) then 
if -1 RM then 

WLastACxi, ai ,x k £ D(x k ) then b k = max(LastPCx i ,a i ,x k +l,LastACx i ,a i ,x k y, 
else fefe = max(LastPCx i ,a i ,x k +l,LastACx i ,a i ,x k +l 
else 

fefe = first value in D(x k ); 
for each £ D(x k ), a k > b k do 
if isConsistent(ai , a k ) then 
if -1 RM then 

if LastACx it ai,x k f. D(% k ) AND LastACx i}ai ,x k > LastPC Xi , ai .x k then 
LastACxi,ai,x k = a k \ 
if searchPCwitifli ,a k ) then 
LastPCxi, ai ,x k = a k ; 

if RM then LastAC Xi ,a i ,x k = a k ; LastPC Xk ,a k . 
witness=TRUE; break; 
if -witness then return false; 
return true; 



If LastPC XiAi)Xk has been removed or ai has no PC- witness in D(xj), we 
search for a new PC-support for ai in D{xk)- As in function searchPCsup, when 
maxRPC3 is used this search starts at an appropriate value calculated taking ad- 
vantage of LastPC Xuai)Xk and LastAC XuauXk (lines 18-20). When maxRPC3 rm 
is used we start from scratch. If an AC-support for a; is found (line 24), we check 
if it is also a PC-support by calling function searchPCwit (line 28). If maxRPC3 is 
used then LastAC XuauXk is updated when necessary (lines 26-27). If a PC-support 
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is found, LastPC x%iaitXk is set accordingly (line 29). If maxRPC3 rm is used then 
the residue LastAC XiiauXk is also updated, as is LastPC Xk! a kiXi (bidirectionality). 
If the search for a PC-support fails then FALSE will be returned, etj will be deleted, 
and X{ will be added to L. 

3.1 Light maxRPC 

Light maxRPC (ImaxRPC) is an approximation of maxRPC that only propagates 
the loss of AC-supports and not the loss of PC-witnesses iflQl . This ensures that 
the obtained algorithm enforces a consistency property that is at least as strong as 
AC. 

ImaxRPC is a procedurally defined local consistency, meaning that its de- 
scription is tied to a specific maxRPC algorithm. Light versions of algorithms 
maxRPC3 and maxRPC3 r "\ simply noted lmaxRPC3 and lmaxRPC3 rm respec- 
tively, can be obtained by omitting the call to the checkPCwit function (lines 11-14 
of Algorithm []]). In a similar way, we can obtain light versions of algorithms 
maxRPC 2 and maxRPC rm . 

As already noted in IflQl . the light versions of different maxRPC algorithms 
may not be equivalent in terms of the pruning they achieve. To give an example, a 
brute force algorithm for ImaxRPC that does not use any data structures can achieve 
more pruning than algorithms lmaxRPC2, lmaxRPC3, and lmaxRPC rm , albeit 
being much slower in practice. Consider that any of these three algorithms will 
return TRUE in case Last PC x „ x is valid. However, although LastPC x . a . x . 
is valid, it may no longer be a PC-support because the PC-witness in some third 
variable may have been deleted, and it may be the last one. In a case where 
LastPC Xij a ijXj was the last PC-support in Xj for value <2j, the three advanced 
algorithms will not delete ai while the brute force one will. This is because it will 
exhaustively check all values of Xj for PC-support, concluding that there is none. 

The worst-case time and space complexities of algorithm ImaxRPC 2 are the 
same as maxRPC2. Algorithm ImaxRPC™ 11 has 0(n 3 d 4 ) time and O(ed) space 
complexities, which are lower than those of maxRPC rm . Experiments with random 
problems using algorithms lmaxRPC rm and maxRPC rm showed that the pruning 
power of ImaxRPC is only slightly weaker than that of maxRPC iPTOl . At the same 
time, it can offer significant gains in run times when used during search. These 
results were also verified by us through a series of experiments on various problem 
classes. 

3.2 Correctness and Complexities 

We now prove the correctness of algorithms maxRPC 3 and maxRPC3 rm and ana- 
lyze their worst-case time and space complexities. 
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Proposition 1 Algorithm maxRPC3 is sound and complete. 

Proof: Soundness. To prove the soundness of maxRPC3 we must prove that any 
value that is deleted by maxRPC3 is not maxRPC. Let € D(x,i) be a value that 
is deleted by maxRPC3. It is either removed from D(xi) during the initialization 
phase (line 15) or in line 8 of AlgorithmQ] after searchPCsup has returned false, or 
in line 12, after searchPCsup has returned true and checkPCwit has returned false. 

In the first case, since function initilization checks all values in a brute-force 
manner, it is clear that any deleted value aj either has no AC-support or none of 
its AC-supports is a PC-support in some variable Xj. The non-existence of a PC- 
support is determined using function searchPCwit whose correctness is discussed 
below. 

In the second case, since searchPCsup returns false, LastPC XuaijX . is not 
valid so a new PC-support in D(xj) is seeked (lines 9-17). This search starts with 
the value at iDax(LastPC XitaijXj +l, LastAC XuauX] ) or at max(LastPC Xitai , Xj 
+ 1, LastAC XitaijXj +1), depending on whether LastAC XuaiiX . is valid or not. 
This is correct since any value before LastPC Xi>aijX ,+l and any value before 
LastAC Xuai)X . is definitely not an AC-support for a, (similarly for the other case). 
searchPCsup will return false either because no AC-support for aj can be found in 
D(xj) (line 10), or because for any AC-support found, searchPCwit returned false 
(line 13). In the former case there is no PC-support for in D(xj) since there is 
no AC-support. In the latter case, for any AC-support aj found there must be some 
third variable x^ for which no PC-witness for the pair (a,i,a,j) exists. For each 
third variable x^ searchPCwit correctly identifies a PC-witness if one of the con- 
ditions in line 3 holds. In none holds then searchPCwit searches for a PC-witness 
starting from mnx(LastAC Xuai)Xk , LastAC Xj:aj:Xk ) (line 6). This is correct since 
LastAC Xuai)Xk and LastAC Xjt a j/Xk are updated with the lexicographically small- 
est support of a,i (resp. a,j) in D(xk) by calling function seekACsup, meaning that 
any value smaller than max(LastAC XuaiiXk , LastAC Xj>ajjXk ) is incompatible with 
either etj or aj. Therefore, if searchPCwit returns false then there is no PC-witness 
for some third variable x\~. Hence, if searchPCsup returns false, it means no PC- 
support for a,i can be found in D(xj) and it is thus correctly deleted. 

Now assume that the call to searchPCsup returned true and was removed 
after checkPCwit returned false. This means that for some variable x/., constrained 
with both Xi and xj, both the first part (lines 3-11) and the second part (lines 13-24) 
of checkPCwit failed to set the Boolean witness to true. Regarding the first part, 
the failure means that the pair of values (aj, a^), where a& is the last PC-support 
of di in D(xk) found, has no PC-witness in D(xj). In more detail, the search for 
a PC-witness correctly starts from max(LastAC XuCHjX ,, LastAC x . a . x ,) in line 
9, after both Last AC pointers have been updated by seekACsup. The condition 
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in line 4 is similar to the corresponding condition in searchPCwit and thus, if it 
is true, the search for PC-witness is correctly overriden. Regarding the second 
part, the failure means that no alternative PC-support for aj in D{xk) was found. 
In more detail, the search for a PC-support starts from max(LastPC Xii a ijXk +l, 
LastAC Xi:aiiXk ) or raax(LastPC Xi ai Xk +l, LastAC x ^ auXk +\), depending on the 
existence of LastAC XuauXk . This is correct since no ealier value can be a PC- 
support. If there is no consistent (aj , a^) pair or searchPCwit returns false for all 
consistent pairs found, then Oj has no PC-support in D{xk) and is thus correctly 
deleted. 

Completeness. To prove the completeness of maxRPC3 we need to show that if 
a value is not maxRPC then the algorithm will delete it. The initialization function 
checks all values of all variables one by one in a brute-force manner and removes 
any value that is not maxRPC. Values that are maxRPC have their LastPC point- 
ers set to the discovered PC-supports. Thereafter, the effects of such removals 
are propagated by calling Algorithm Q] and as a result new value deletions may 
occur. Now consider a value aj € D(xi) that was not removed by the initializa- 
tion function but after propagation is no longer maxRPC. This is either because of 
PC-support or PC-witness loss. 

In the first case assume that xj is the variable in which aj no longer has a PC- 
support. Since the previously found PC-support of aj has been deleted, Xj must 
have been added to Q at some point. When xj is removed from Q all neighbor- 
ing variables, including Xj will be checked. Function searchPCsup will find that 
LastPC Xij a ijX is no longer valid and will search for a new PC-support concluding 
that there is none. Therefore, it will return false and Oj will be deleted. 

In the second case assume that the pair of values (a,i,aj), where aj is the 
last PC-support of aj in D(xj), has lost its last PC-witness in variable Xk- If 
LastPC Xij a tjXj is not valid, which means that xj was added to Q, then we have the 
same case as above. Therefore, after xj is removed from Q, searchPCsup will find 
out that there is no PC-support for aj in D(xj) and will delete it. If LastPC Xua ^ Xj 
is valid then searchPCsup will return true (line 2). Since was deleted, Xk was 
added to Q at some point. When Xk is removed from Q all neighboring vari- 
ables, including Xj will be checked. If a, has no longer a PC-support in D(xk), 
this will be detected by searchPCsup and a, will be deleted. Otherwise, function 
checkPCwit will be called. The for loop in line 1 will go through every variable 
constrained with both X{ and Xk, including Xj. Since LastPC Xuai)X . is valid, a 
new PC-witness for {ai,af) in D(xk) will be seeked (lines 3-11). Since was 
the last PC-witness, none will be found and as a result a new PC-support for aj 
in D(xj) will be seeked (lines 13-24). Since aj was the last PC-support for aj in 
D(xj), none will be found, checkPCwit will return false, and aj will be deleted. 
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Proposition 2 Algorithm maxRPC3 rm is sound and complete. 

Proof: The proof is very similar to the corresponding proof for maxRPC3. As 
explained, the main difference between the two algorithms concerns the use of 
the Last AC and LastPC structures. As maxRPC3 rm does not maintain these 
structures incrementally, the searches for PC-supports in searchPCsup and check- 
PCwit and the searches for PC-witnesses in searchPCwit and checkPCwit start 
from scratch. Clearly, this has no effect on the soundness or completeness of 
the algorithm since it guarantees that all potential PC-supports and PC-witnesses 
are checked. Furthermore, the conditions for avoiding redundant searches using 
residues are the same as in maxRPC3. Finally, another difference between the two 
algorithms is the exploitation of bidirectionality by maxRPC3 rm . By the defini- 
tion of path and arc consistency, bidirectionality holds. That is, when a PC-support 
(AC-support) aj G D{xj) is located for a value a, G D(xi) then ai is a PC-support 
(AC-support) for aj. Since the property of bidirectionality is exploited only to 
update residues, it does not affect the correctness of the algorithm. 

We now discuss the complexities of algorithms maxRPC3 and maxRPC3 rm 
and their light versions. To directly compare with existing algorithms for 
(l)maxRPC, the time complexities give the asymptotic number of constraint check^l. 
Folllowing 10, the node time (resp. space) complexity of a (l)maxRPC algorithm 
is the worst-case time (resp. space) complexity of invoking the algorithm after 
a variable assignment. The corresponding branch complexities of an (l)maxRPC 
algorithm are the worst-case complexities of any incremental sequence of k < n 
invocations of the algorithm. That is, the complexities of incrementally running 
the algorithm down a branch of the search tree until a fail occurs. 

Proposition 3 The node and branch time complexity of ( 1 ) maxRPC3 is 0(end 3 ). 

Proof: The complexity is determined by the total number of calls to function 
isConsistent in searchPCsup, checkPCwit, and mainly searchPCwit where most 
checks are executed. 

Each variable can be inserted and extracted from L every time a value is deleted 
from its domain, giving 0(d) times in the worst case. Each time a variable Xj is 
extracted from L, searchPCsup will look for a PC-support in D(xj) for all values 
<ij G D(xi), s.t. Cj j G C. For each variable Xi, 0(d) values are checked. Checking 
if a value aj G D(xj) is a PC-support involves first checking in 0(1) if it is an 
AC-support (line 9 in searchPCsup) and then calling searchPCwit. The cost of 

3 However, constraint checks do not always reflect run times as other operations may have an 
equal or even greater effect. 
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searchPCwit is 0(n + nd) since there are 0(n) variables constrained with both 
Xi and Xj and, after making the checks in line 3, their domains must be searched 
for a PC-witness, each time from scratch with cost 0(nd). Through the use of 
LastPC no value of Xj will be checked more than once over all the 0(d) times Xj 
is extracted from L, meaning that for any value a, G D(xi) and any variable Xj, the 
overall cost of searchPCwit will be 0(dn + nd 2 ) = 0(nd 2 ). Hence, searchPCsup 
will cost 0(nd 2 ) for one value of Xi, giving 0(nd 3 ) for d values. Since, in the 
worst case, this process will be repeated for every pair of variables x% and Xj that 
are constrained, the total cost of searchPCsup will be 0(end 3 ). This is the node 
complexity of lmaxRPC3. 

In checkPCwit the algorithms iterate over the variables in a triangle with Xj 
and Xi. In the worst case, for each such variable x^, D(xj) will be searched from 
scratch for a PC-witness of Oj and its current PC-support in xu- As xj can be ex- 
tracted from L 0(d) times and each search from scratch costs 0(d), the total cost 
of checking for a PC-witness in D(xj), including the checks of line 4 in check- 
PCwit, will be 0(d + d 2 ). For d values of x^ this will be 0(d 3 ). As this process 
will be repeated for all triangles of variables, whose number is bounded by en, 
its total cost will be 0(end 3 ). If no PC-witness is found then a new PC-support 
for ctj in D(xk) is seeked through searchPCwit. This costs 0(nd 2 ) as explained 
above but it is amortized with the cost incurred by the calls to searchPCwit from 
searchPCsup. Therefore, the cost of checkPCwit is 0(end 3 ). This is also the node 
complexity of maxRPC3. 

The branch complexity of ( 1 ) maxRPC3 is also 0(en<i 3 ). This is because the 
use of LastPC ensures that for any constraint aj and a value a« € D(xi), each 
value of Xj will be checked at most once for PC-support while going down the 
branch. Therefore, the cost of searchPCwit is amortized. 

Proposition 4 The node and branch time complexities of lmaxRPC3 rm and 

maxRPC3 r ' m are 0(end A ) and 0(en 2 d i ) respectively. 

Proof: The proof is similar to that of Proposition [3] The main difference with 
lmaxRPC3 is that since last PC is not updated incrementally, each time we seek 
a PC-support for a value Oj € D(xi) in Xj, D(xj) will be searched from scratch in 
the worst case. This incurs an extra 0(d) cost to searchPCsup and searchPCwit. 
Hence, the node complexity of lmaxRPC3 rm is 0(end A ). Also, the total cost of 
searchPCwit in one node cannot be amortized. This means that the cost of search- 
PCwit within checkPCwit is 0(nd 2 ). Hence, the node complexity of maxRPC3 rm 
is 0(en 2 d A ). The branch complexities are the same because the calls to search- 
PCwit are amortized. 
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The space complexities of the algorithms are determined by the space required 
for data structures LastPC and Last AC. Since both require 0(ed) space, this is 
the node space complexity of (1 ) maxRPC3 and ( 1 ) maxRPC 3 rm . (l)maxRPC3 
has O(end) branch space complexity because of the extra space required for the in- 
cremental update and restoration of the data structures. As ( 1 ) maxRPC 3 rm avoid 
this, its branch space complexity is 0{ed). 

4 Heuristics for maxRPC Algorithms 

Numerous heuristics for ordering constraint or variable revisions have been pro- 
posed and used within AC algorithms ifTTl [3l ITTl . Heuristics such as the ones used 
by AC algorithms can be also used within a maxRPC algorithm to efficiently select 
the next variable to be removed from the propagation list (line 5 of Algorithm [T]). 
In addition to this, maxRPC and ImaxRPC algorithms can benefit from the use of 
heuristics elsewhere in their execution. Once a variable Xj has been removed from 
the propagation list, heuristics can be applied as follows in either a maxRPC or a 
ImaxRPC algorithm (we use algorithm (1 ) maxRPC3 for illustration): 

1. After a variable Xj is removed from L all neighboring variables Xi are re- 
vised. ImaxRPC (resp. maxRPC) will detect a failure if the condition of 
PC-support loss (resp. either PC-support or PC-witness loss) occurs for all 
values of Xj. In such situations, the sooner X{ is considered and the fail- 
ure is detected, the more constraint checks will be saved. Hence, the order 
in which the neighboring variables of Xj are considered can be determined 
using a fail-first type of heuristic. 

2. Once an AC-support aj € D(xj) has been found for a value a-i G D{xj), 
searchPCsup tries to establish if it is a PC-support. If there is no PC-witness 
for the pair (aj, aj) in some variable x\. then aj is not a PC-support. There- 
fore, we can again use fail-first heuristics to determine the order in which the 
variables forming a triangle with X{ and Xj are considered. 

The above cases apply to both ImaxRPC and maxRPC algorithms. In addition, 
a maxRPC algorithm can employ heuristics as follows: 

3. For each value aj € D(xi) and each variable Xk constrained with both xi and 
Xj, Function |4] checks if the pair (aj, a^) still has a PC- witness in D(xj). If 
there is no PC-witness or LastPC Xii(HiXk is not valid then a new PC-support 
in Xk is seeked. If none is found then aj will be deleted. Again heuristics 
can be used to determine the order in which the variables constrained with 
Xi and Xj are considered. 
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4. In Function[4]if LastPC Xi>ai>Xk is not valid then a new PC-support for ai in 
D{xk) is seeked. The order in which variables constrained with both Xj and 
Xk are considered can be determined heuristically as in Case 2 above. 

As explained, the puipose of such ordering heuristic will be to "fail-first". That 
is, to quickly discover potential failures (Case 1 above), refute values that are not 
PC-supports (Cases 2 and 4) and delete values that have no PC-support (Case 3). 
Such heuristics can be applied in any coarse-grained maxRPC algorithm to de- 
cide the order in which variables are considered in Cases 1-4. Examples are the 
following: 

dom Consider the variables in ascending domain size. This heuristic can be ap- 
plied in any of the four cases. 

del_ratio Consider the variables in ascending ratio of the number of remaining 
values to the initial domain size. This heuristic can be applied in any of the 
four cases. 

wdeg In Case 1 consider the variables X{ in descending weight for the constraint 
Cij. In Case 2 consider the variables x^ in descending average weight for the 
constraints cq. and cjk- Similarly for Cases 3 and 4. 

dom/wdeg Consider the variables in ascending value of dom/wdeg. This heuristic 
can be applied in any of the four cases. 

Experiments demonstrated that applying heuristics in Cases 1 and 3 are partic- 
ularly effective, while doing so in Cases 2 and 4 saves constraint checks but only 
marginally reduces cpu times. All of the heuristics mentioned above for Cases 1 
and 3 offer cpu gains, with dom/wdeg being the most efficient. Although the pri- 
mal puipose of the heuristics is to save constraint checks, it is interesting to note 
that some of the heuristics can also divert search to different areas of the search 
space when a variable ordering heuristic like dom/wdeg is used, resulting in fewer 
node visits. For example, two different orderings of the variables in Case 1 may 
result in different constraints causing a failure. As dom/wdeg increases the weight 
of a constraint each time it causes a failure and uses the weights to select the next 
variable, this may later result in different branching choices. This is explained for 
the case of AC in (H. 

5 Experiments 

We have experimented with several classes of structured and random binary CSPs 
taken from C.Lecoutre's XCSP repository. Excluding instances that were very hard 
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for all algorithms, our evaluation was done on 200 instances in total from various 
problem classes. More details about these instances can be found in C.Lecoutre's 
homepage. All algorithms used the dom/wdeg heuristic for variable ordering (H 
and lexicographic value ordering. In case of a failure (domain wipe-out) the weight 
of constraint is updated (right before returning in line 15 of Algorithm Q]). The 
suffix '+H' after any algorithm's name means that we have applied the dom/wdeg 
heuristic for ordering the propagation list [13, and the same heuristic for Case 1 de- 
scribed in Section 4. In absense of the suffix, the propagation list was implemented 
as a FIFO queue and no heuristic from Section 4 was used. 

Table 1 : Average stand-alone performance in all 200 instances grouped by problem 
class. Cpu times (t) in sees and constraint checks (cc) are given. 



Problem class 




maxRPC2 


maxRPC3 


lmaxRPC2 


lmaxRPC3 


ImaxRPC™ 


lmaxRPC3™ 


lmaxRPC3+H 


RLFAP 


t 


6.786 


2.329 


4.838 


2.043 


4.615 


2.058 


2.148 


(seen, graph) 


cc 


31M 


9M 


21M 


8M 


21M 


9M 


8M 


Random 


t 


0.092 


0.053 


0.079 


0.054 


0.078 


0.052 


0.056 


(modelB .forced) 


cc 


0.43M 


0.1 8M 


0.43M 


0.1 8M 


0.43M 


0.1 8M 


0.1 8M 


Geometric 


t 


0.120 


0.71 


0.119 


0.085 


0.120 


0.086 


0.078 




cc 


0.74M 


0.35M 


0.74M 


0.35M 


0.74M 


0.35M 


0.35M 


Quasigroup 


t 


0.293 


0.188 


0.234 


0.166 


0.224 


0.161 


0.184 


(qcp,qwh,bqwh) 


cc 


1.62M 


0.59M 


1.28M 


0.54M 


1.26M 


0.54M 


0.54M 


QueensKnights, 


t 


87.839 


47.091 


91.777 


45.130 


87.304 


43.736 


43.121 


Queens, QueenAttack 


cc 


489M 


188M 


487M 


188M 


487M 


188M 


188M 


driver.blackHole 


t 


0.700 


0.326 


0.630 


0.295 


0.638 


0.303 


0.299 


haystacksjob-shop 


cc 


4.57M 


1.07M 


4.15M 


LOOM 


4.15M 


LOOM 


LOOM 



Table Q] compares the performance of stand-alone algorithms used for prepro- 
cessing. We give average results for all the instances, grouped into specific problem 
classes. We include results from the two optimal coarse-grained maxRPC algo- 
rithms, maxRPC2 and maxRPC3, from all the light versions of the coarse-grained 
algorithms, and from one of the most competitive algorithms (maxRPC3) in tan- 
dem with the dom/wdeg heuristics of Section|4](lmaxRPC3+H). Results show that 
in terms of run time our algorithms have similar performance and are superior to 
existing ones by a factor of two on average. This is due to the elimination of many 
redundant constraint checks as the cc numbers show. Heuristic do not seem to 
make any difference. 

Tables [2] and [3] compare the performance of search algorithms that apply 
ImaxRPC throughout search on RLFAPs and an indicative collection of other 
problems respectively. The algorithms compared are lmaxRPC rm and 
lmaxRPC3 T ' m with and without the use of heuristic dom/wdeg for propagation 
list and for Case 1 of Section 01 We also include results from MAC rm which is 
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considered the most efficient version of MAC (8j|9l. 

Table 2: Cpu times (t) in sees, nodes (n) and constraint checks (cc) from RLFAP 
instances. Algorithms that use heuristics are denoted by their name + H. The best 
cpu time among the ImaxRPC methods is highlighted. 



instance 




AC™ 


ImaxRPC™ 


lmaxRPC3™ 


ImaxRPC'" 1 + H 


lmaxRPC3 rm + H 


scenl 1 


t 


5.4 


13.2 


4.6 


12.5 


4.3 




n 


4,367 


1,396 


1,396 


1,292 


1,292 




cc 


5M 


92M 


29M 


90M 


26M 


scenll-flO 


r 


11.0 


29.0 


12.3 


22.3 


9.8 




n 


9,597 


2,276 


2,276 


1,983 


1,983 




cc 


11M 


141M 


51M 


114M 


41M 


scen2-f25 


t 


27.1 


109.2 


43.0 


79.6 


32.6 




n 


43,536 


8,310 


8,310 


6,179 


6,179 




cc 


44M 


427M 


151M 


315M 


113M 


scen3-f 1 1 


t 


7.4 


30.8 


12.6 


17.3 


7.8 




n 


7,962 


2,309 


2,309 


1,852 


1,852 




cc 


9M 


132M 


46M 


80M 


29M 


scenl l-f7 


t 


4,606.5 


8,307.5 


3,062.8 


6,269.0 


2,377.6 




n 


3,696,154 


552,907 


552,907 


522,061 


522,061 




cc 


4,287M 


35.897M 


9,675M 


22,899M 


6,9 13M 


scenl l-f'8 


t 


521.1 


2,680.6 


878.0 


1,902.4 


684.7 




n 


345,877 


112,719 


112,719 


106,352 


106,352 




cc 


638M 


10.163M 


3.172M 


7,585M 


2,3 14M 


graph8-fl0 


t 


16.4 


16.8 


9.1 


11.0 


6.3 




n 


18,751 


4,887 


4,887 


3,608 


3,608 




cc 


14M 


71M 


31M 


51M 


21M 


graph 14-f28 


t 


31.4 


4.1 


3.1 


2.6 


2.1 




n 


57,039 


2,917 


2,917 


1,187 


1,187 




cc 


13M 


17M 


8M 


13M 


6M 


graph9-f9 


t 


273.5 


206.3 


101.5 


289.5 


146.9 




n 


273,766 


26,276 


26,276 


49,627 


49,627 




cc 


158M 


729M 


290M 


959M 


371M 



Experiments showed that lmaxRPC rm is the most efficient among existing al- 
gorithms when applied during search, which confirms the results given in ifTOll . Ac- 
cordingly, ImaxRPC 3 rm is the most efficient among our algorithms. It is between 
two and four times faster than maxRPC 3 rm on hard instances, while algorithms 
lmaxRPC3 and lmaxRPC2 are not competitive when used during search because 
of the data structures they maintain. In general, when applied during search, any 
maxRPC algorithm is clearly inferior to the corresponding light version. The re- 
duction in visited nodes achieved by the former is relatively small and does not 
compensate for the higher run times of enforcing maxRPC. 

Results from Tables |2] and [3] demonstrate that ImaxRPC 3 rm always outper- 
forms lmaxRPC rm , often considerably. This was the case in all 200 instances 
tried. The use of heuristics improves the performance of both ImaxRPC algo- 
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rithms in most cases. Looking at the columns for lmaxRPC rm and lmaxRPC3 rm 
+H we can see that our methods can reduce the numbers of constraint checks by as 
much as one order of magnitude (e.g. in quasigroup problems qcp and qwh). This 
is mainly due to the elimination of redundant checks inside function searchPCwit. 
Cpu times are not cut down by as much, but a speed-up of more than 3 times can 
be obtained (e.g. scen2-f25 and scenll-f8). 

Table 3: Cpu times (t) in sees, nodes (n) and constraint checks (cc) from various 
instances. 



instance 




AC™ 


ImaxRPC™ 


lmaxRPC3™ 


ImaxRPC™ + H 


lmaxRPC3™ + H 


rand-2-40-8 


t 


4.0 


47.3 


21.7 


37.0 


19.0 


-753-100-75 


n 


13,166 


8,584 


8,584 


6,915 


6,915 




cc 


7M 


289M 


82M 


207M 


59M 


geo50-20 


t 


102.7 


347.7 


177.5 


273.3 


150.3 


d4-75-l 


n 


181,560 


79,691 


79,691 


75,339 


75,339 




cc 


191M 


^ f\ A C ~K A 

2,045M 


O OAR A 

880M 


1.437M 


609M 


qcpl50-120-5 


t 


52.1 


89.4 


50.2 


80.0 


55.3 




n 


233,311 


100,781 


100,781 


84,392 


84,392 




cc 


27M 


329M 


53M 


224M 


36M 


qcpl50-120-9 


t 


226.8 


410.7 


238.1 


239.9 


164.3 




n 


1,195,896 


583,627 


583,627 


315,582 


315,582 




cc 


123M 


1.613M 


250M 


718M 


112M 


qwh20- 166-1 


t 


52.6 


64.3 


38.9 


21.2 


14.9 




n 


144,653 


44,934 


44,934 


13,696 


13,696 




cc 


19M 


210M 


23M 


53M 


6M 


qwh20- 166-6 


t 


1,639.0 


1,493.5 


867.1 


1,206.2 


816.5 




n 


4,651,632 


919,861 


919,861 


617,233 


617,233 




cc 


633M 


5,()89M 


566M 


3,100M 


35 1M 


qwh20- 166-9 


t 


41.8 


41.1 


25.0 


39.9 


28.5 




n 


121,623 


32,925 


32,925 


26,505 


26,505 




cc 


15M 


135M 


15M 


97M 


11M 


blackHole 


t 


1.8 


14.4 


3.8 


12.1 


3.6 


4-4-e-8 


n 


8,661 


4,371 


4,371 


4,325 


4,325 




cc 


4M 


83M 


12M 


68M 


10M 


queens- 100 


t 


15.3 


365.3 


106.7 


329.8 


103.0 




n 


7,608 


6,210 


6,210 


5,030 


5,030 




cc 


6M 


1.454M 


377M 


1,376M 


375M 


queenAttacking5 


t 


34.3 


153.1 


56.7 


136.0 


54.8 




n 


139,534 


38,210 


38,210 


33,341 


33,341 




cc 


35M 


500M 


145M 


436M 


128M 


queensKnights 


t 


217.0 


302.0 


173.6 


482.0 


283.5 


-15-5-mul 


n 


35,445 


13,462 


13,462 


12,560 


12,560 




cc 


153M 


963M 


387M 


1J95M 


869M 



Importantly, the speed-ups obtained can make a search algorithm that effi- 
ciently applies ImaxRPC competitive with MAC on many instances. For instance, 
in scenl 1-f 10 we achieve the same run time as MAC while lmaxRPC rm is 3 times 
slower while in scenl l-f7 we go from 2 times slower to 2 times faster. In addition, 
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there are several instances where MAC is outperformed (e.g. the graph RLFAPs 
and most quasigroup problems). Of course, there are still instances where MAC 
remains considerably faster despite the improvements. 



Table 4: Average search performance in all 200 instances grouped by class. 



Problem class 




AC™ 


ImaxRPC™ 


lmaxRPC3™ 


ImaxRPC™ + H 


lmaxRPC3™ + H 


RLFAP 


t 


242.8 


556.7 


199.3 


416.3 


157.3 


(scen,graph) 


cc 


233M 


2.306M 


663M 


1.580M 


487M 


Random 


t 


8.4 


28.0 


14.8 


28.5 


17.1 


(modelB .forced) 


cc 


14M 


161M 


60M 


137M 


51M 


Geometric 


t 


21.5 


72.2 


37.2 


57.6 


32.1 




cc 


39M 


418M 


179M 


297M 


126M 


Quasigroup 


t 


147.0 


162.5 


94.9 


128.9 


89.6 


(qcp,qwh,bqwh) 


cc 


59M 


562M 


68M 


333M 


40M 


QueensKnights, 


t 


90.2 


505.2 


180.3 


496.4 


198.1 


Queens, QueenAttack 


cc 


74M 


1,865M 


570M 


1,891M 


654M 


driver,blackHole 


t 


3.2 


17.1 


9.1 


11.9 


7.0 


haystacks job-shop 


cc 


1.8M 


55M 


6.4M 


36.7M 


5.1M 



Table [4] summarizes results from the application of ImaxRPC during search. 
We give average results for all the tested instances, grouped into specific prob- 
lem classes. As can be seen, our best method improves on the existing best one 
considerably, making ImaxRPC outperform MAC on the RFLAP and quasigroup 
problem classes. Overall, our results demonstrate that the efficient application of a 
maxRPC approximation throughout search can give an algorithm that is quite com- 
petitive with MAC on many binary CSPs. This confirms the conjecture of [6] about 
the potential of maxRPC as an alternative to AC. In addition, our results, along with 
ones in |[T0l . show that approximating strong and complex local consistencies can 
be very beneficial. 

6 Conclusion 

We presented maxRPC3 and maxRPC3 r "\ two new algorithms for maxRPC, and 
their light versions that approximate maxRPC. These algorithms build on and im- 
prove existing maxRPC algorithms, achieving the elimination of many redundant 
constraint checks. We also investigated heuristics that can be used to order certain 
operations within maxRPC algorithms. Experimental results from various problem 
classes demonstrate that our best method, ImaxRPC 3 rm , constantly outperforms 
existing algorithms, often by large margins. Significantly, the speed-ups obtained 
allow lmaxRPC3 rm to compete with and outperform MAC on many problems. In 
the future we plan to adapt techniques for using residues from @ to improve the 
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performance of our algorithms during search. Also, it would be interesting to in- 
vestigate the applicability of similar methods to efficiently achieve or approximate 
other local consistencies. 
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